\chapter{DAS-4 network}

The DAS-4 supercomputer is primarily used for scientific research and distributed applications testing. Comprised of multiple wide-ares clusters, the computational grid needs to have a high speed network in order to address latency, throughput and capacity issues that might arise with applications using multiple clusters for the execution of their workload. Optical mesh networks are a well-known solution that address all of these concerns. This chapter elaborates further on the design of the DAS-4 all-photonic network. 


\section{Optical network design}

The key component of the DAS-4 network, which enables the all-optical interconnections, is the Degree-4 PXC. Fig. x a shows the University sites connected by the PXC. Two groups of
four and three bi-directional 10 Gb/s optical channels from the head nodes at UvA, VU, Delft, Leiden and ASTRON  are physically connected to the PXC. Each color in the shown logical setups maps to a unique wavelength, chosen from the domain 1558.17nm to 1561.01nm on a 50 GHz grid, with eight possible channels in total (TODO ref), a limitation posed by the physical characteristics of splitters and WSSs shown in Fig 1 b. In order to solve the limitation, a wavelength resuse scheme containing four wavelengths, takes care of conducting assignments in a way, which guarantees no wavelength contention would occur at a given head node. The StarPlane network is used for connecting the different University sites.

The lack of opto-electronic conversions provides pure de-coupling of the WDM control plane and the IP data plane. Signalling as well as Routing and Wavelength Assignment (RWA) in the optical control plane are all provided by the OpenNSA protocol, thereby eliminating the need for signalling protocols such as Generalized Multiprotocol Label Switching (GMPLS) (TODO ref) and loose-coupling of optical and IP infrastructure via standards such as User to Network Interface (UNI) (TODO ref RFC).



\section{IP addressing and routing}

DAS-4's clusters are connected together with Linux-based routers. Each head node has interfaces for connecting to StartPlane via a varying number of 10Gbps optical transceivers, to equipment in the computational cluser via a single 10Gbps transceiver and to the Internet via 1Gbps twisted-pair copper. Fig. x shows an overview of interfaces connecting to StarPlane as well as switches in each respective cluster.
\newpage
\begin{figure}[h]
	%\begin{center}
			\includegraphics[width=4.7in]{/home/madave/Dropbox/school/RP2/das4-routing/report/figures/das4addressing.jpg} 
	%\end{center}
	\caption{DAS-4 StarPlane interfaces and cluster addressing.\textcolor{red}{TODO add router WANs}}
\end{figure}
\vskip2em

Interfaces with matching colors represent the default network configuration which provides connectivity to all sites. In such a configuration, a star topology is observed with VU serving as an intermediate hop between any other pair of clusters. Solid colored lines represent the currently existing interfaces, whereas dotted ones interfaces planned for provisioning.

At current, changes that need to be applied to IP addressing, routing and capacity provisioning after each reconfiguration of the optical network are dealt with by Network Administrators. 


 any change performed in the optical layer is handled by changes in routing and link aggregation 
Allocating more than 10Gbps of bandwitdh between clusters is performed by manual intervention of network administrators. After reservation and provisioning of multiple lightpaths between two sites, with each lightpath spanning betwee a pair of interfaces, manual scripts configure link aggregation, logical addressing and static routes.

\textcolor{red}{TODO diagram providing all lightpath configurations and capacities}

\textcolor{red}{elaborate that addressing is fluid, manually picked as per a configuration}

\section{Automating IP addressing and routing}

\begin{itemize}
\item all done by hand

\item benefits of the automation process?
\begin{itemize}
\item no need for static routing rules and coordination between admins

\item will accommodate network growth in terms of the planned interfaes with ease
\end{itemize}

\item complications presented by the process
\begin{itemize}
\item a routing protocol is not enough
\item devices from different subnets may be paired
\item scripts needed for adjusting interface addressing and advertised networks in OSPF  
\end{itemize}
\end{itemize}




